The purpose of this article is to explain the changes to how audio is handled under Windows Windows Vista™, and how we are planning to address this.

What level of compatibility exists between XP and Windows Vista™ drivers?

Default Driver Model: WDM
As with Windows NT, Windows 2000 and Windows XP, the foundation of Windows Windows Vista™ is the Windows NT kernel, and as with Windows 2000 and Windows XP, the default driver model is the Windows Driver Model (WDM). This portion of Windows Vista™ has remained remarkably unchanged with Windows XP.
WDM Port Class Models
Also, as with Windows 2000 and Windows XP, the foundation of any WDM audio device driver has remained unchanged. All PCI WDM audio drivers are based upon the WDM audio "Port Class" and Windows Windows Vista™™ supports all Windows XP "Mini Port" models, including "Wave Cyclic" and "Wave PCI". Also, all USB / 1394 WDM audio drivers are based upon "Stream Class" or "A/V Stream".
WDM Kernel Streaming
As a result of this, any WDM driver that was built under Windows XP should generally work as is under Windows Windows Vista™ without a recompile. Also, any user mode programs that use "WDM Kernel Streaming" (such as Cakewalk SONAR) in Windows XP would work exactly the same under Windows Windows Vista™™, when run on top of the driver that was built for Windows XP.

So what has changed?

New Miniport Type: Wave RT
Microsoft has added a third "Miniport" type for PCI products that is unique to Windows Vista™, which is called "Wave RT".
(http://www.microsoft.com/whdc/device/audio/wavertport.mspx)
The promise of Wave RT is that user mode applications could completely govern streams of audio without any code execution in the kernel during runtime.

1. Wave RT allows the user mode application direct access to the data in the memory that is mapped to the audio hardware DMA engine
2. Wave RT allows the application to poll the current position in the DMA memory window that the hardware is accessing.
3. Wave RT also supports the notion of a hardware generated clock notification event, similar to the ASIO API, so that applications need not poll for current position if they don't want to.

Wave RT is the new standard, but WavePCI and WaveCyclic are still supported
Microsoft did realize that it would be difficult to get other vendor's legacy audio drivers moved over to the WaveRT model, because a lot of legacy hardware cannot support this model. So, Microsoft still continues to support the two "Miniport" driver models that were used in Windows XP ("WavePCI" and "WaveCyclic"), which means "WaveRT" drivers are not strictly required under Windows Vista™.

If the new Wave RT format is not strictly required, why do I need new drivers for Windows Vista™?

The similarities start and end at the kernel miniport level. After that, everything changes.
What has changed dramatically in Windows Windows Vista™ is the main OS audio subsystem. This is the part of the OS that handles audio coming from multiple user mode client applications, audio mixing, processing and sample rate conversion. What has also changed radically in Windows Windows Vista™™ is the emulation of the Windows standard audio APIs, Windows Multimedia Extensions ("MME") and "DirectSound".


The Windows XP audio architecture could be depicted as follows:



Windows XP audio architecture Click to enlarge

In this model, both DirectSound and MME may be emulated over the OS audio stack, which was mostly implemented in kernel mode. A low level "Kernel Mixer" (or kMixer) is used to facilitate multiple user mode client applications, audio mixing, processing and sample rate conversion. However, also note that a direct path from DirectSound straight to the audio driver also existed. This was the path that facilitated audio acceleration in DirectSound. Proprietary APIs such as ASIO and OpenAL bypass all of that and go straight to the lowest level of the driver.

The Windows Windows Vista™ audio architecture could be depicted as follows:



Windows Windows Vista™ audio architecture Click to enlarge

This is derived from a diagram from this website: http://blogs.msdn.com/larryosterman/archive/2006/03/07/545451.aspx, which is an article from the web log of a Microsoft audio developer.

Audio Flow through Windows Vista™ - introducing WASAPI and APOs
The above picture depicts audio flow through Microsoft's new user mode audio architecture. An application communicates through this path through what is depicted as Sessions, and these Sessions are programmed through what Microsoft calls Windows Audio Session API (or WASAPI).
http://windowssdk.msdn.microsoft.com/en-us/library/ms679162.aspx

The other blocks represent various points where some form of host based audio processing happens (sample rate conversion, mixing, effects). Host based processing modules are also referred to as Audio Processing Objects, or APOs. The above link has more details on the meaning of the other acronyms.

More User Mode, Less Kernel Mode
In this model, nearly all blocks in the picture above run in user space. The only portion of this architecture that runs in kernel mode is represented by the single block called "Audio Driver", and it contains only a minimal amount of Microsoft code. It contains only the Microsoft "Port Class" Driver, the Vendor "Miniport" driver and Vendor Hardware Abstraction Layer portions depicted in the XP driver architecture diagram. Note that the Windows "Kernel Mixer" (or kMixer) is completely gone.

Changes to Direct Sound and MME implementation
Windows "Direct Sound" and "MME" emulation have also radically changed. These emulation layers now sit exclusively on top of the depicted Windows Vista™ audio architecture, and are basically "Session" instances. "Session 1" could be looked at as an MME application going through a Microsoft emulation layer, and "Session 2" could be looked at as a DirectSound 3D application going through a Microsoft emulation layer.

Reasons for Change
Microsoft had stated reasons for these kinds of radical changes that go beyond "the need to change things". Reasons include moving as much software out of kernel mode as possible thereby minimizing bug checks (in layman's terms "BSODs"), developing an architecture to make debugging audio problems in applications easier, and supporting a whole new generation of Digital Rights Managemen
(http://www.microsoft.com/whdc/device/stream/output_protect.mspx)
A further description for the rationale of these changes may be seen in this Microsoft developer's web log entry:
(http://blogs.msdn.com/larryosterman/archive/2005/09/19/471346.aspx)

These changes had a number of unfortunate side effects.

kMixer dependency issues
First, while all efforts were made to work with all legacy Windows XP audio drivers, the global graph communication to the audio driver does differ from the way kMixer communicated to the audio driver, in terms of timing and processing blocks and demands for more precise reporting of sample position. As a result, any legacy Windows XP audio driver whose behavior depended on kMixer specific behavior could break in Windows Windows Vista™, if Windows Windows Vista™ subjects the driver to an unexpected condition. This was ultimately the root cause of several bugs found in Audigy and X-Fi drivers for Windows Windows Vista™, such as audio dropouts, distortions that only happen once a while, constant distortions, or audio/video synchronization drift that only happens after several hours of watching movies.These bugs are being addressed now

Pre-mixed Audio
Second, with the way this new emulation structure, all "MME" and "Direct Sound" applications will ultimately result in pre-mixed PCM audio that is sent to the driver in one and only one format (in terms of sample rate, bit depth and channel count), and that format is governed by a control panel setting that Microsoft would prefer be configured only by the end user. This eliminates any opportunity for hardware to accelerate sample rate conversion or to take full advantage of advanced SRC technologies such as the ones used in the X-Fi product
(http://www.soundblaster.com/products/x-fi/technology/lastinfo/ssrc.asp) when using standard operating system audio.

Direct Sound 3D HW Acceleration - RIP
In addition, unlike Windows XP, there is no "Direct" path from DirectSound applications to audio drivers or hardware at all. DirectSound is emulated into a Windows audio "Session", as depicted here:



DirectSound Click to enlarge

The diagram below puts this in perspective in the context of the entire audio architecture. Note that DirectSound implementation is circled in red:



Entire Windows Vista™ audio architecture Click to enlarge

Note that the Windows Vista™ DirectSound emulation sends mixed audio content to the standard OS audio path, and offers no "direct" path to hardware at all. Since the whole point of DirectSound acceleration is to allow hardware to process unmixed audio content, DirectSound cannot be accelerated in this audio model.

Game Audio Issues
This results in bugs such as loss of EAX functionality in games to complete incompatibility, depending on how the game title was authored and how well the Microsoft DirectSound emulation code works. In addition, given this model any and all bugs that are exclusive to DirectSound games could not possibly be due to Creative audio drivers or any other IHV (Independent Hardware Vendors) audio drivers.

Custom Audio Effect APOs
Windows Vista™ does support insertion points for custom audio effects
(http://www.microsoft.com/whdc/device/audio/sysfx.mspx, http://www.microsoft.com/whdc/device/audio/Vista_sysfx.mspx)
depicted above as APO1 and APO3. Forthcoming Creative audio products will use APOs to implement certain features, but these custom effects do not allow acceleration of DirectSound because as mentioned above they receive mixed content, not unmixed content.

Creative supported hardware acceleration for Gaming and Music Creation
The good news here is that, as depicted above, Windows Vista™ still permits proprietary user mode to kernel mode driver stacks, which means that Creative products may continue to support non Microsoft driver models and technologies such as
OpenAL (http://www.openal.org) for 3D gaming,
SoundFont Management System (http://www.soundfont.com)
ASIO (http://www.steinberg.net) for audio content creation.
As was the case in Windows XP, these audio interfaces will continue to be thin pedal-to-the-metal APIs that allow user mode applications to access hardware features directly.

OpenAL - the key to optimum audio for gaming in Windows Windows Vista™
OpenAL continues to be the most widely used API for optimum 3D sound in PC gaming and the direct to hardware path offered by this API is the only way to access the hardware accelerated audio processing offered by cards in the Sound Blaster range.
Combined with Creative's high precision SRC technology, patented 3D audio spatialization and EAX technology, multi-channel / multi-speaker rendering, EAX 5.0 DSP effects, Crystalizer and CMSS technology, Creative's Sound Blaster X-Fi continues to be THE ultimate audio solution for Windows gaming.
While the Microsoft architecture works very well for simple multimedia applications such as music listening and moving watching, these technologies will continue to offer optimal performance with minimal CPU impact in gaming and music creation applications for years to come.